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(54) Method for enhancing operation of a network management system 



(57) A generic notifications framework (GNF) sys- 
tem (103) integrates information from different protocols 
(302) in a management station (100) interlaced with a 
network (1 18) and permits correlation of the information 
to make more sophisticated management decisions. 
The generic notifications framework system (103) has 
one or more protocol-specific translators (252) in com- 
munication with the network (118), a generic notifica- 
tions framework (254) in communication with the 
translators (252), and one or more consumer compo- 
nents (534) in communication with the framework (254). 
The translators (252) receive event data elements 
(424c) corresponding with different management proto- 
cols (302) from the network (118) and translate the 
event data elements (424c) into respective canonical 
data structures (424). Each of the canonical data struc- 
tures (424) includes (a) a generic field (424a) that is 
common to generally all of the canonical data structures 
(424), (b) one or more attribute fields (427) generated 
by the translator (252) based upon an examination of a 
protocol data unit (PDU) (424c) associated with each of 
the event data elements (424c), and (c) a protocol data 
unit (PDU) (424c) that is generally identical to the native 
PDU that arrived with the event data element. Con- 
sumer components (534) register with the framework 
(254) to receive any canonical data structures (424) 
having particular attribute fields (427). The generic noti- 
fications framework (254) forwards the appropriate 
canonical data structures (424) to appropriate con- 
sumer components (534) based upon the attribute field 
(427) values. A correlator (1406) may be associated 
with the framework (254) to correlate the canonical data 
structures (424) to derive an intelligent event data ele- 



ment, which is essentially the result of an assimilation 
and logical evaluation of various event data elements 
(424c). 
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Description 

FIELD OF THE INVENTION 

The present invention generally relates to data 5 
communication networks, and more particularly, to a 
generic notifications framework (GNF) system and 
method for integrating information from different proto- 
cols in a management station interfaced with a network 
and for permitting correlation of the information to make 10 
more sophisticated management decisions regarding 
the network or station. In addition to network manage- 
ment, these management decisions can also be 
directed to higher level system management in the case 
of distributed systems or distributed management appli- 75 
cations operating above the network. 

BACKGROUND OF THE INVENTION 

A data communications network generally includes 20 
a group of devices, for instance, computers, repeaters, 
bridges, routers, etc., situated at network nodes and a 
collection of communication channels for interconnect- 
ing the various nodes. Hardware and software associ- 
ated with the network and particularly the devices 2s 
permit the devices to exchange data electronically via 
the communication channels. 

in order to keep track of and manage the various 
devices situated on a network, various management 
protocols have been developed. Examples of these 30 
management protocols include the Simple Network 
Management Protocol (SNMP), the Common Manage- 
ment Information Protocol (CMIP) standardized by the 
International Organization for Standardization (ISO), 
proprietary protocols that can be found in proprietary 35 
network environments, such as SNA™ from IBM Corp. 
and "NETWARE"™ (N W) from Novell Corp., and remote 
procedure call protocols (RPC), such as the distributed 
computing environment protocol (DCE-RPC) that was 
developed by the Open Software Foundation. The use 40 
of the foregoing protocols has become extensive in the 
industry, and numerous vendors now manufacture 
many types of network devices which can employ these 
protocols. 

Many management software packages ("manage- 45 
ment platforms") are presently available for implement- 
ing "management stations" on a network. Examples of 
commercially available management software pack- 
ages include "OPENVIEW™ (or "HP OPENVIEW™) 
from the Hewlett-Packard Company, which is the so 
assignee herein, "NETVIEW"™ from IBM Corp., "SPEC- 
TRUM"™ from Cabletron Systems. Inc., "NETLABS 
MANAGER"™ from NetLabs, Inc., and "SUN NET MAN- 
AGER"™ from SunConnect Inc. The nodes on the net- 
work and their interconnections, oftentimes referred to ss 
as the network "topology," are best displayed in a graph- 
ical format, and most, if not all, of the available manage- 
ment software packages provide for this feature. 
Typically, with these packages, a network can be viewed 



from different vantage points, depending on the scope 
of the view that is desired. For example, one view of the 
network could be a very wide encompassing view of all 
nodes on the entire network A second view could be a 
view of those portions of a network within a local range, 
for example, within a particular site or building. A third 
view of a network, often called a segment, could be a 
view of nodes attached to a particular local area net- 
work (LAN) cable. 

Hewlett-Packard's very successful "OPEN VIEW"™ 
has been the subject of several patents, including for 
instance, U.S. Patent No. 5,185,860 issued to J.C. Wu 
on February 9, 1993, and U.S. Patent No. 5,276,789 
issued to Besaw et af. , on January 4, 1994. U.S. Patent 
No. 5,185,860 describes an automatic discovery sys- 
tem for a management system for determining the net- 
work devices and interconnections of a network, or the 
topology. U.S. Patent No. 5,276,789 describes a graphic 
display system for a management station for graphically 
displaying the topology of a network and provides for 
various views (including, internet, segment, and node 
views) that can be requested by a user. 

Although the presently available management sta- 
tions are meritorious to an extent, the art of manage- 
ment stations is still in a state of infancy, and the 
performance of current management stations can still 
be enhanced and optimized. A specific area where opti- 
mization is envisioned involves the sharing of informa- 
tion derived from events among applications that are 
associated with the management stations. Herein, an 
"event" is a notification emitted by any element in the 
managed environment to indicate a change in state. 
Events are typically asynchronous relative to the man- 
agement station. Moreover, there already exist numer- 
ous event forwarding and distribution mechanisms, but 
each is highly tuned to a particular environment or pro- 
tocol domain. This predicament causes several prob- 
lems. 

First, many applications require access to notifica- 
tions for more than one of the protocol domains making 
up the managed environment. However, their imple- 
mentation is currently complicated due to the number 
and variety of protocols and interfaces required. Appli- 
cation access to event data should not be burdened by 
a required understanding of the detailed syntax and 
semantics of environment-specific protocols, represen- 
tations of, and interfaces to. the event data. 

Second, there is no single, common mechanism for 
gathering notifications from multiple domains. In the 
context of this document, a "notification" is any mes- 
sage that is emitted asynchronously with respect to a 
receiver and in a logically non-directed fashion. In some 
cases, specific modules have been created to map noti- 
fications from one mechanism to another, but this 
results in an "n by m" problem and often distorts the 
information because of the target's environment-spe- 
cific, often nonapplicable elements. In some cases, 
information from an original notification is lost alto- 
gether, because there is no semantically comparable 
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structure in the target. 

Third, applications do not have a common integra- 
tion mechanism for exchanging asynchronous mes- 
sages among the applications. 

Fourth, there is little in the way of shared semantics 
between applications to allow the creation of generic 
functions. Specifically, there is no current way to imple- 
ment a common event management console, a com- 
mon filtering mechanism, or common tools that can be 
applied to all variants of event data. 

Thus, a heretofore unaddressed need exists in the 
industry for a system and method for enhancing opera- 
tion of a management station on a network by integrat- 
ing and correlating information from different protocols. 

SUMMARY OF THE INVENTION 

Briefly described, the present invention is a generic 
notifications framework (GNF) system and method for 
integrating information from different protocols in a man- 
agement station interlaced with a network and for per- 
mitting correlation of the information to make more 
sophisticated management decisions. 

Structurally, the generic notifications framework 
system has one or more protocol-specific translators in 
communication with the network, a generic notifications 
framework in communication with the translators, and 
one or more consumer components in communication 
with the framework. The translators receive event data 
elements corresponding with different management 
protocols from the network and translate the event data 
elements into respective canonical data structures. 
Each of the canonical data structures includes (a) a set 
of generic fields that are common to all of the canonical 
data structures, (b) one or more attribute fields gener- 
ated by the translator based upon an examination of a 
protocol data unit (PDU) associated with each of the 
event data elements, and (c) a protocol data unit (PDU) 
that is generally identical to the native PDU that arrived 
with the event data element. In essence, the PDU in the 
canonical data structure is an encapsulation of any 
native data so applications that understand the repre- 
sentation have full access to its contents. 

Consumer components register with the framework 
to receive any canonical data structures having particu- 
lar values for attribute fields. Moreover, the generic noti- 
fications framework forwards the appropriate canonical 
data structures to appropriate consumer components 
based upon the values of the attribute fields. 

A correlator, optionally but preferably, may be asso- 
ciated with the framework to correlate the canonical 
data structures to derive an intelligent event data ele- 
ment, which is essentially the result of an assimilation 
and logical evaluation of various event data elements. 
Hence, event data elements are treated and processed 
generically, and this feature permits more sophisticated 
decisions to be made. 

The present invention provides a generic notifica- 
tions framework method for enhancing operation of a 



management station on a network by integrating infor- 
mation from different management protocols, as fol- 
lows: receiving event data elements corresponding with 
different management protocols from the network; 

5 translating the event data elements into respective 
canonical data structures, each of the canonical data 
structures including at least one attribute field gener- 
ated by examining a protocol data unit associated with 
each of the event data elements; passing the canonical 

10 data structures to a framework for possible distribution 
to consumer components that are connected to the 
framework; communicating a particular attribute field 
from a consumer component to the framework to indi- 
cate that the consumer component wishes to receive 

is any of the canonical data structures with the particular 
attribute field; and forwarding a canonical data structure 
with the particular attribute field from the framework to 
the consumer component. 

Furthermore, the present invention provides a 

20 method for enhancing operation of a management sta- 
tion on a network by both integrating and correlating 
information from different management protocols, as 
follows: receiving event data elements from the net- 
work; translating each of the event data elements into a 

25 canonical data structure, the canonical data structure 
capable of being correlated with other canonical data 
structures corresponding to other event data elements 
regardless of protocols associated with the event data 
elements; and correlating the canonical data structures 

so to derive an intelligent event, which is essentially an 
action resulting from a high level intelligent decision 
derived from assimilation and evaluation of various 
events. 

The present invention has numerous advantages, a 

35 few of which are delineated hereafter, as examples. 

An advantage is that a protocol-neutral representa- 
tion of each event can be accomplished, which greatly 
simplifies the creation of common management mecha- 
nisms, filters, displays, and tools. 

40 Another advantage is that asynchronous messages 
can be exchanged between applications that operate in 
accordance with different protocols. 

Another advantage is that the interface between 
applications is simplified. 

45 Another advantage is that applications do not need 
to understand the detailed syntax and semantics of 
environment-specific protocols, representations of, and 
interfaces to, the event data in order to communicate 
between each other. 

so Another advantage is that information from different 
protocols can be integrated and correlated so that more 
sophisticated decisions can be made concerning man- 
agement. 

Another advantage is that more sophisticated deci- 
55 sions can be made for networked computing environ- 
ments having multiple heterogeneous networks and 
network management protocols. 

Other features and advantages of the present 
invention will become apparent to one with skill in the art 
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upon examination of the following drawings and detailed 
description, tt is intended that all such additional fea- 
tures and advantages be included herein within the 
scope of the present invention, as is defined in the 
accompanying claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention can be better understood 
with reference to the following drawings. Note that like 
reference numerals within the drawings designate cor- 
responding parts. 

Fig. 1 is a block diagram illustrating an example of 
implementation of the generic notifications frame- 
work (QNF) system of the present invention in a 
management station, which is the best mode 
known at present for practicing the invention; 
Fig. 2 is a block diagram illustrating the discov- 
ery/layout software and the GNF system of Fig. 1 : 
Fig. 3 is a block diagram illustrating the GNF of Fig. 
1 interfacing various environment-specific event 
subsystems that operate upon events having differ- 
ent protocols; 

Fig. 4 is a schematic diagram illustrating the canon- 
ical data structure for event data that is communi- 
cated through the GNF system of Fig. 1 ; 
Fig. 5 is a block diagram illustrating the roles {i.e., 
supplier, consumer, and configurator) that are 
assumed by components that interact with the GNF 
system of Fig. 1 ; 

Fig. 6 is a block diagram illustrating an example of a 
supplier in the form of an event subsystem of Fig. 3; 
and 

Fig, 7 is a block diagram illustrating an alarm sub- 
system having correlation functions that is 
employed in connection with the GNF of Fig. 1 . 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBQPIMENTS 

The generic notifications framework (GNF) system 
of the present invention can be stored on any computer- 
readable medium for use by or in connection with a 
computer-related system or method. In the context of 
this document, a computer-readable medium is an elec- 
tronic, magnetic, optical, or other physical device or 
means that can contain or store a computer program for 
use by or in connection with a computer-related system 
or method. 

The GNF system and method can be implemented 
in virtually any environment that processes asynchro- 
nous events that concern the resources being managed 
in a network, a distributed network, or other communi- 
cation system. In the preferred embodiment, the GNF 
system and method are implemented in a management 
station. A management station is any machine that runs 
at least a portion of the management system. An exam- 
ple of a management station is discussed hereafter for 



purposes of discussion. 

Fig. 1 shows a block diagram of a management sta- 
tion 100 which is implemented with a general purpose 
computer system containing discovery/layout software 

s 101, which utilizes the GNF system 1 03 and associated 
methodology of the present invention. With reference to 
Fig. 1, the management station 100 contains any suita- 
ble processor 102. The processor 102 communicates to 
other elements within the management station 100 over 

io a local interface 104, for instance, a bus or buses. An 
input device 106, for example, a keyboard or mouse, is 
used to input data from a user of the management sta- 
tion 100, and an output device 108, for example, a dis- 
play or printer, is used to output data to the user. A 

75 network interface 1 12 is used to interface the manage- 
ment station 100 to a network 1 18 or group of networks 
in order to allow the management station 1 00 to act as 
a node on the network 118 or group of networks. A 
memory 1 10 within the management station 100 stores 

so the software for driving the processor 1 02 and generally 
the station 100. 

As shown, in this embodiment, the memory 110 
can include the following hierarchy of software: at the 
highest logical level, one or more management applica- 

25 tons 105; at the next logical level, discovery/layout soft- 
ware 101 situated in a logical sense alongside of the 
GNF system 103; and at the bwest logical level, a con- 
ventional operating system 122 and conventional net- 
work software 124. The one or more management 

30 applications 105 manage, at a high level, an aspect of 
the network 1 18 or group of networks. Both the discov- 
ery/layout software 101 and the GNF system 103 can 
communicate with the operating system 122 and net- 
work software 1 24 to discover the nodes on the network 

35 118. The network software 124 serves as the intelli- 
gence, including validation, for the data communication 
protocols. As shown in Fig. 1 , the network software has 
subsystems 302 that can implement, as examples, the 
following protocols: SNMP, CMIP, DCE, and proprietary 

40 protocols of the SNA and NW. All of the foregoing proto- 
cols are well known in the art. 

Generally, the discovery/layout software 101 of Fig. 
1 is configured to discover the network topology, that is, 
all network nodes and node interconnections existing 

45 on the network 1 1 8, and to construct a map, comprising 
various submaps, any of which can be used for output- 
ting the network topology on the output device 108. 

A high level block diagram of the GNF system 103 
and the discovery/layout software 101 (Fig. 1) is set 

so forth in Fig. 2. With the exception of the GNF system 
103, the architecture of the discovery/layout software 
101 in Fig. 2 is essentially the same as or similar to the 
architecture of Hewlett-Packard's well known and com- 
mercially available management software package 

55 called "OPENVIEW™. As shown in Fig. 2. at a general 
architecture level, the discovery/layout software 101 
comprises a discovery mechanism 202 for discovering 
nodes and interconnections of the network 118 and a 
layout mechanism 204 for receiving topology data from 
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the discovery mechanism 202 and for generating the 
map for driving the output device 108. Moreover, one or 
more management applications 105 may communicate 
display and map information with the layout mechanism 
204. 5 

The discovery mechanism 202 has a network mon- 
itor 206 connected to the network 1 18 as indicated by 
connection 208, a topology manager 210 connected to 
the network monitor 206 as indicated by arrows 212 and 
through the generic notifications framework (QNF) sys- 10 
tern 103 that will be described in detail at a later point in 
this document, and a topology data base 2 1 4 in commu- 
nication with the topology manager 210 as indicated by 
arrow 216. 

The network monitor 206 transmits and receives is 
data packets to and from the network 118. The network 
monitor 206 discovers and monitors network topology, 
as indicated by arrow 208. When network topology 
changes on the network, the network monitor 206 gen- 
erates events, or traps (SNMP vernacular), which 20 
include an object identifier and object change informa- 
tion. The network monitor 206 can also receive events 
from other devices, such as a router, in the network 1 1 8. 
The network monitor 206 interacts with the network 1 18 
by way of the network software 124 (Fig. 1), which 25 
essentially comprises protocol stacks, corresponding to. 
for example. IP. TCP. UDP. SNMP. ISO, DCE, SNA. and 
NW, and which generally implements these protocols 
and performs validation functions. Furthermore, the net- 
work monitor 206 populates the topology data base 214 30 
by way of the topology manager 210 and notifies the 
topology manager 210 of events (topology changes). 
Finally, it should be noted that US. Patent No. 
5,185,860 to Wu, which is incorporated herein by refer- 
ence, describes an example of a node discovery system 35 
which could be employed to implement the network 
monitor 206 herein. The foregoing monitor focuses 
upon monitoring events pertaining to changes in topol- 
ogy. Other monitors could be employed in connection 
with the present invention and directed to monitoring ao 
other aspects of the environment, in which case other 
types of management information might be passed 
through the monitor and the GNF system 103. 

The topology manager 210 manages the topology 
data base 214, as indicated by bidirectional arrow 216. 45 
The topology manager 210 prompts the network moni- 
tor 206 to update topology data related to particular 
events and receives topology updates, as indicated by 
arrow 212. 

The topology data base 214 stores topology data so 
based upon objects, which are used to partition the net- 
work for logical reasons. Objects include, for example 
but not limited to, a network, a segment, a computer, a 
router, a repeater, a bridge, etc. Moreover, the topology 
data stored with respect to the objects includes, for ss 
example but not limited to, an interface or device 
address, a device type, a device manufacturer, and 
whether an interface or device supports the SNMP. 

The layout mechanism 204 has a topology-to-map 



translator 218 in communication with the topology man- 
ager 210 as indicated by arrow 220, a graphical user 
interface (GUI) 222 in communication with the topology- 
to-map translator 218 as indicated by arrow 224, and a 
map data base 226 in communication with the GUI 222 
as indicated by bidirectional arrow 228. The one or 
more applications 105 communicate information with 
the GUI 222, as indicated by arrow 233. 

The translator 218 converts topology data received 
from the topology data base 214 and the GNF system 
103 into map data and constructs various submaps in 
the map. The translator 2 1 8 can forward a request to the 
topology manager 210, as indicated by arrow 220, in 
order to obtain topology data regarding particular 
objects. In addition to forwarding topology data to the 
translator 218 upon request, the topology manager 210 
advises the translator 218, as indicated by respective 
arrows 220, when topology data has changed based 
upon an event so that the translator 218 can make any 
appropriate changes in the submaps. 

Furthermore, the translator 218 can register with 
the GNF system 103 to receive a certain type of topol- 
ogy data or event. In turn, when appropriate, the topol- 
ogy manager 210 and the GNF system 103 forward the 
topology data to the translator 218. as indicated by 
respective arrows 220, 245. The GNF registration fea- 
ture eliminates the need for the translator 218 to keep 
making requests (polling) for desired data. 

The GUI 222 manages the map data base 226, as 
indicated by the arrow 228, and manages the input 
device 106 and output device 108, as indicated by the 
respective arrows 230. 231 . The GUI 222 receives map 
updates from the translator 218 and submits user-trig- 
gered events to the translator 21 8, as indicated by arrow 
224. A user-triggered event includes a request 230 from 
a user to explode an object. Finally, it should be noted 
that U.S. Patent No. 5,276,789 to Besaw et al. , which is 
incorporated herein by reference, describes a graphical 
user interface which could be employed to implement 
the GUI 222 herein. 

The GNF system 103 of the present invention is in 
communication with the network monitor 206, the topol- 
ogy manager 210, the GUI 222, and the one or more 
applications 105, as indicated by respective arrows 242, 
244, 246, and 248 in Fig. 2. In general, the GNF system 
103 enables the sharing of events from different man- 
agement protocols, such as SNMP, ISO, DCE, SNA, 
and NW ( and permits correlation of the information to 
make more sophisticated management decisions. 

The GNF system 103 comprises an event translator 
254 and a GNF 254, which are in communication as 
indicated by reference arrow 253. The translator 252 is 
configured to translate event data into a canonical data 
structure (Fig. 4), which is capable of being correlated 
with other canonical data structures corresponding to 
other event data, regardless of protocols associated 
with the event data. Further, the canonical data struc- 
ture enables the GNF system 254 to perform common 
semantic operations, such as filtering, forwarding, trac- 



9 



EP0810 755 A2 



10 



ing, and logging. The canonical data structures are for- 
warded by the translator 252 to the GNF 254, which can 
filter the canonical data structures and forward the 
structures to any consumers, such as the topology man- 
ager 210, the GUI 222, or an application 105. 5 

Fig. 3 is a block diagram illustrating the communica- 
tion links that can be established by the GNF system 
103 in the station 100 (Fig. 1). The GNF system 103 
interfaces one or more environment-specific event sub- 
systems 302 conforming to various different protocols 10 
and, further, interfaces the various subsystems 302 with 
the one or more applications 105. The GNF system 103 
serves as an integration point where event information 
pertaining to events concerning the network 118 is 
shared. The environment-specific event subsystems is 
302 can be directed to any suitable protocol, for 
instance, SNMP, CMIP, and DCE-RPC, or those proto- 
cols provided by SNA and NW. In the preferred embod- 
iment, the subsystems 302 are situated within or 
associated with the network monitor 206 (Fig. 2). More- 20 
over, one of the management applications 302 can be, 
for example, an alarm subsystem, as is shown in Fig. 3. 

The canonical data structure is shown in Fig. 4 and 
generally denoted by reference numeral 424. The 
canonical data structure 424 includes generic fields 25 
424a, extracted attributes 424b. and a native protocol 
data unit (PDU) 424c. tn a sense, when transmitted, the 
canonical data structure 424 itself is a form of PDU. The 
generic fields 424a are those few attributes which can 
be considered common (or nearly common) to all envi- 30 
ronment-specif ic formats. The extracted attributes are a 
collection of fully-specified attributes, including name, 
type, length, and value, which have been extracted from 
the native formats so they can be interpreted by any 
receiver. The environment-specific PDU 24c is an 35 
encapsulation of any native data so applications that 
understand the representation have full access to its 
contents. For some advisory types, a native format may 
not exist or apply, in which case the environment-spe- 
cific PDU 424c and, perhaps, the extracted attributes 40 
424b would be empty. An "advisory" is a notification 
emitted by an element of the management station 100 
(Fig. 1) for the purpose of keeping its normal workings 
properly synchronized. As an example, the structure of 
this canonical data structure 424 can be specified by an 45 
object management group (OMG) interface definition 
language (IDL) {i.e., an OMG IDL defined data struc- 
ture), which is a commercially available language for 
describing object interfaces and data structures. 

The generic fields 424a are those that are present so 
in all canonical data structure notifications, have a 
widely understood semantic, and have useful values in 
the vast majority of notification instances. The number, 
position, and type of these fields is fixed, and therefore, 
they may be used by any element in the environment for 55 
filtering functions. There are relatively few of these 
generic fields 424a. In a preferred embodiment, the 
generic fields include: a source designation 426a, which 
is a string (printable) containing a name for the entity 



which originally generated the notification; an environ- 
ment type 426b, which designates the kind of notifica- 
tion or the environment in which it originated (examples 
include generic, SNMP, DCE, SNA, NW, CMIP, ete.; 
these must be unique values and thus must be handled 
via a registration service or be inherently unique); an 
origination time 426c, which is the time at which the 
notification was injected into the GNF system 103; an 
extracted attributes number 426d, which is the number 
of extracted attributes that follow; and a PDU length 
426e, which indicates the length of the native PDU 424c 
as attached to this notification (preferably, a length of 
zero indicates no native PDU present). 

The number of extracted attributes 424b is variable 
in the canonical data structure 424. The extracted 
attributes 424b comprise a sequence of 4-tuple 
attributes 427a-427d containing a name 428a, a type 
428b, a length 428c, and a value 428d. Because all ele- 
ments in this sequence are explicit, operations, such as 
comparisons for filtering, may be performed on them 
with confidence and without a need to extend the infra- 
structure for the introduction of new field names. The 
types available include those defined by the OMG IDL. 
The attributes 427a-427d may actually be extracted 
from an environment-specific PDU 424c when it is 
mapped to the canonical data structure 424 (hence the 
name) or simply a variable portion of the notification (in 
the case of advisories). 

The PDU 424c is essentially a string of bits that is 
uninterpreted by the GNF system 103, but is maintained 
by the GNF system 103. The PDU 424c usually com- 
prises the original, domain specific, event PDU, but may 
be used to pass any other information that will not be 
interpreted by the GNF system 103, but will be for- 
warded by it. 

The roles that can be played by components which 
interact with the GNF 254 of the GNF system 103 will 
now be described with reference to Fig. 5. Essentially, 
there are three roles that can be played by components 
which interact with the GNF system 103: supplier 532 
(e.g., the network monitor 206), consumer 534 [e.g., 
the topology manager 210, the GUI 222, an application 
105), and configurator 536 (e.g., the network monitor 
206, the topology manager 210, the GUI 222, an appli- 
cation 105). The supplier 532 injects management sig- 
nals into the GNF 254 of the GNF system 103, as 
indicated by reference arrow 538, whereas the con- 
sumer 534 receives management signals from the GNF 
254, as indicated by the reference arrow 539. The GNF 
254 receives management signals from the supplier 
based upon registration of the supplier with the GNF 
254, as denoted by reference arrow 542, and the GNF 
254 transfers management signals to the consumer, 
based upon registration of the consumer 534 with the 
GNF 254, as denoted by reference arrow 544. In 
essence, the consumer 534 can inform the configurator 
536 what it is interested in, and the configurator 536 can 
establish a filter for same. 

The configurator 536 configures the supplier 532 
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and the GNF 254, as indicated by respective reference 
arrows 535, 537 and receives configuration information 
from the consumer 534, as indicated by reference arrow 
543. Note that in the figures, configuration accesses are 
indicated by narrow elongated bars. The aforemen- 
tioned exchange of configuration information ensures 
consistency among management signals injected, for- 
warded, and received via the GNF 254. tt should be 
noted that the foregoing roles are entirely logical in 
nature. A given application or service may in fact play 
any one, two, or all three of these roles. 

At initialization (or possibly later), the configurator 
536 adds one or more filters 541 that the GNF 254 is to 
use in distributing specific management signals. The 
configurator 536 can then set up suppliers 532 to inject 
management signals of interest into the GNF 254. If 
translation from a native format into the canonical data 
structure 424 (Fig. 4) is being performed by the supplier 
532, then the configurator 536 may specify additional 
variations, such as which native attributes are to be 
extracted. At this point, the supplier 532 understands its 
mission and can register itself with the GNF 254 so that 
the GNF 254 can begin generating management sig- 
nals 539. 

The consumer 534 may likewise require configura- 
tion by the configurator 536, if the consumer 534 retains 
the flexibility to dynamically process various manage- 
ment signals 539. In this scenario, the configurator 536 
responds to a filter request from the consumer 534 by 
forwarding the response to the GNF 254, and the 
response is ultimately communicated to the consumer 
534 via the GNF 254. Once the configuration has been 
established, the consumer 534 knows which new sig- 
nals to register with the GNF 254, as delineated by ref- 
erence arrow 544. The consumer registration simply 
associates the consumer with the results of a filter. 

Hence, the meeting point (pipe or event channel) 
may be either established by the consumer 534 and 
communicated to the configurator 536 or established by 
the configurator 536 in response to a filter request from 
the consumer 534 and communicated back to the con- 
sumer 534. In either case, this meeting point is where 
the GNF 254 places events that pass the associated fil- 
ter. 

After the required configuration has taken place, 
the supplier 532 can generate management signals 
538, which are distributed by the GNF system 103 for 
consumption by the consumer 534, as indicated by the 
reference arrow 539. 

In terms of implementation, it is important to 
remember that these roles (i.e.. supplier, consumer, 
and configurator) are logical in nature. Consequently, 
the role of configurator 536 may in practice be sepa- 
rated among several components or its presence may 
not even be apparent, if it is imbedded within the sup- 
plier 532 or the consumer 534. Furthermore, a number 
of the aforementioned configuration steps are optional 
in that they may not be required by all the implementa- 
tions or uses of the GNF system 1 03, especially if a par- 



ticular supplier 532 and consumer 534 are static in 
terms of the management signals they handle. 

With reference to Fig. 6, suppliers 532 may be 
implemented as event translators 252, which can be 

5 dedicated to process events pertaining to the protocols 
SNMP, CMIP, DCE, proprietary protocols of SNA, NW, 
etc. The event translators 252 and their corresponding 
event subsystems 302 are interconnected with the net- 
work 1 1 8 and receive events 602 from the network 1 1 8. 

w Events are sent to a specific address and port that cor- 
respond to each event translator 252 and the event sub- 
system 302. Each event subsystem 302 forwards 
events 604 to its corresponding event translator 252. 
Moreover, the event translator 252 converts the event 

is data, /. e. , the PDU, into the canonical data structure 424 
(Fig. 4) and transfers the canonical data structure 424 to 
the GNF 254, as indicated by reference arrow 253 in 
Fig. 6. 

The event translators 252 are configured by the 
20 configurator 536 (Fig. 5), as indicated by arrow 606 in 
Fig. 6, with respect to which environment-specific PDU 
attributes need to be pulled out as extracted attributes 
427a-427d (Fig. 4) in the canonical data structure 424 
(Fig. 4). Additionally, when the event translators 252 are 
25 configured, K is their responsibility to configure their 
associated event subsystem 302 to filter and forward its 
appropriate events to the event translator 252 so that 
the event translator 252 can relay the selected events to 
the GNF 254. 

30 Optionally, the GNF 254 may be equipped with a 
trace mechanism 610 and an event log mechanism 612. 
The trace mechanism 610, unlike the event log mecha- 
nism 61 2, applies to all management signals introduced 
into the GNF 254. The trace mechanism 610, like the 

35 event log mechanism 612, follows the consumer model 
in providing a consumer to receive all management sig- 
nals and to capture a brief written record of its occur- 
rence. The trace mechanism 610 can serve as a 
debugging and support aid and can be designed for 

40 managing management processes themselves. 

The event log mechanism 612 is used to capture a 
record of all event type management signals that have 
been introduced into the GNF 254. Particularly, the 
event log mechanism 612 preserves the data of the 

45 canonical data structure 424 (Fig. 4) for event manage- 
ment signals, described earlier, so that interested appli- 
cations can access the generic fields 424a, the 
extracted attrfoutes 424b, and the PDU 424c. 

Moreover, the event log mechanism 612 provides a 

so basis for event correlation and alarm mapping, 
described hereinafter, plus it provides a historical record 
of the events that have occurred across all the managed 
environments. The event log mechanism 612 should, of 
course, be configurable to log only the events of inter- 

55 est; not all events forwarded into the GNF 254 need 
necessarily be placed in data storage. As such, it is 
important to note that the event log mechanism 612 has 
its own consumer that receives and writes the events 
into the data base. The only difference between this 
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consumer and consumers 534 is that the log consumer 
is built directly into the GNF 254 for increased perform- 
ance. 

Both the trace mechanism 610 and the event log 
mechanism 612 should be provided with configurable s 
interfaces to specify storage policy so available memory 
does not overflow and entries are deleted according to 
a deliberately chosen method. 

The GNF system 103 can be implemented in con- 
nection with an alarm subsystem 702, as is illustrated in 10 
Fig. 7. In essence, the alarm subsystem 702 uses the 
GNF system 103 in its management of alarms. In the 
context of this document, an "alarm" is a recorded inter- 
pretation, with state, of one or more events. The alarm 
subsystem 702 comprises the components used for 15 
defining, updating, storing, presenting, and giving 
access to alarms. In architecture, the alarm subsystem 
702 comprises an alarm service 704, one or more cor- 
relators 706 (or correlators), and an alarm console 708. 
The alarm service 704 provides alarm storage services 20 
710, based upon data received from the correlators 706 
and the console 708, as is indicated by respective refer- 
ence arrows 712, 714. The correlators 706 determine 
when alarms are created. Finally, the console 708 com- 
prises user interface tools for viewing and manipulating 25 
alarms. 

The input 716 to the correlators 706 can be pro- 
vided by any management application 105 (Fig. 2) that 
listens to management signals or provided by any other 
relevant or suitable input. The GNF 254 enables imple- 30 
mentation of the correlators 706. The correlators 706 
monitor the current state of the managed environment 
against alarm conditions or incoming notifications to 
determine when the alarm conditions are true. As these 
conditions become true, the correlators 706 create new 35 
alarms by interacting with the alarm service 704. 

The alarm service 704 has two primary functions: 
to provide an interlace which gives access to alarm 
records in data storage and to generate management 
signals which communicate alarm state changes to 40 
interested applications 105 (Fig. 2). As the correlators 
706 detect alarm condition state changes, the correla- 
tors 706 invoke the alarm service 704 to create the cor- 
responding alarm or update their state values. Similarly, 
any application 105 can use the alarm service 704 to 45 
retrieve an alarm or make appropriate changes to the 
alarms. In the preferred embodiment, the data that is 
available from an alarm record includes: when the alarm 
became true, when the alarm became false, its state, a 
reference to the definition of its alarm condition, and a so 
list of the particular event identifications which made the 
alarm condition true. 

As the alarm state changes occur, the alarm serv- 
ice 704 generates management signals 718 for the 
GNF 254 to notify registered applications 105 of the 55 
changes. These alarm states include, for example but 
not limited to, alarm creation (or validity), alarm 
acknowledgement, alarm deletion, alarm invalidity (or 
no longer true), alarm escalation, etc. 



The console 708 comprises various tools for alert- 
ing the user to alarm state changes and enabling the 
user to view and manipulate alarms. Examples include 
an alarm monitor and record browser, an events monitor 
and browser, a trouble-ticketing system, and an alarm 
configurator used for defining alarm conditions and reg- 
istering user interest in particular alarms. Note that an 
events monitor and browser can be an integral part of 
the alarm console 708, because it is primarily events 
which constitute alarm conditions. 

An example of an alarm to show operation of the 
alarm subsystem 702 is as follows. Assume that the 
memory 124 (Fig. 1) in the form of a hard disk drive is 
running out of memory storage space. A correlator 706 
could be dedicated to monitoring events and determin- 
ing when the disk memory 124 is approaching full 
capacity. When the foregoing correlator 706 determines 
that the disk memory 124 is approaching full capacity, 
the correlator 706 issues a disk low notification 712 to 
the alarm service 704, which in turn issues a disk low 
notification 718 to the GNF 254. The GNF 254 then 
issues the disk low notification 720 to a registered 
action server 722, which consumes the notification and 
executes a script that handles activities to obtain more 
space in the disk memory 124. There are numerous 
other examples of alarms, and the aforementioned 
example should not be limiting. 

In concluding the detailed description, it should be 
noted that it will be obvious to those skilled in the art that 
many variations and modifications may be made to the 
preferred embodiments without substantially departing 
from the principles of the present invention. All such var- 
iations and modifications are intended to be included 
herein within the scope of the present invention, as is 
set forth in the following claims. Further, in the claims 
hereafter, the structures, materials, acts, and equiva- 
lents of all means-plus-function or step-plus-function 
elements are intended to include any structures, materi- 
als, or acts for performing the specified functions. 

Claims 

1. A generic notifications framework system (103) for 
enhancing operation of a management station 
(100) on a network (118) by integrating information 
from different management protocols (302), com- 
prising: 

a translator (252) connected to said network 
(118) to receive event data elements (424c) 
corresponding with different management pro- 
tocols (302) from said network (118), said 
translator (252) configured to translate said 
event data elements (424c) into respective 
canonical data structures (424), each of said 
canonical data structures (424) including at 
least one attribute field (427) generated by said 
translator (252) upon examination of data 
associated with each of said event data ele- 
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merits (424c); and 

a generic notifications framework (254) con- 
nected to said translator (252) to receive said 
canonical data structure, said framework (254) 
configured to forward a canonical data struc- s 
ture with a particular attribute field (427) to a 
consumer component (534) connected to said 
framework (254), said consumer component 
(534) having previously registered with said 
framework (254) to receive any of said canoni- 10 
cal data structures (424) with said particular 
attribute field (427). 

2. The system (103) of claim 1, further comprising a 
correlator (1406) configured to correlate said is 
canonical data structures (424) to derive an intelli- 
gent event. 

3. The system (103) of claim 1, wherein said canoni- 
cal data structure further includes a generic field 20 
(424a) that designates a protocol (424c) corre- 
sponding to said event data element. 

4. The system (1 03) of claim 1 , further comprising: 

25 

a plurality of event subsystems (302) con- 
nected to said network (118). each one of said 
event subsystems (302) adapted to receive 
event elements (424c) from said network (118) 
having a particular protocol (424c) associated 30 
said each one; and 

a plurality of translators (252), one of which is 
said translator (252), each of which are con- 
nected to a respective one of said event sub- 
systems (302), and all of which are connected 35 
to said framework (254) to provide said canon- 
ical data structures (424) to said framework 
(254). 

5. The system (103) of claim 2, further comprising a 40 
configurator (536) connected to said framework 
(254) and configured to specify which of said 
canonical data structures (424) are to be forwarded 

to said correlator (1406). 

45 

6. The system (103) of claim 4, further comprising a 
configurator (536) connected to said translators 
(252) and configured to specify which of said event 
data elements (424c) are to be communicated by 
each said translator (252) to said generic notifica- so 
tion framework (254). 

7. The system (103) of claim 5, wherein said configu- 
rator (536) is further connected to said translator 
(252) and is further configured to specify which of 55 
said event data elements (424c) are to be commu- 
nicated by said translator (252) to said generic noti- 
fication framework (254). 



8. An intelligent integration system (700) for enhanc- 
ing operation of a management station (100) on a 
network (118) by correlating and integrating infor- 
mation from different protocols (302), comprising: 

a receiver connected to said network (118) to 
receive evenl data elements (424c) corre- 
sponding to different protocols (302) from said 
network (118); 

a translator (252) connected to said receiver, 
said translator (252) configured to translate 
each of said event data elements (424c) into a 
canonical data structure, said canonical data 
structure capable of being correlated with other 
canonical data structures (424) corresponding 
to other event data elements (424c) regardless 
of protocols (302) associated with said event 
data elements (424c); and 
a correlator (706) connected to said translator 
(252), said processor configured to correlate 
said canonical data structures (424) to derive 
an intelligent event. 

9. A method for enhancing operation of a manage- 
ment station (1 00) on a network (1 1 8) by integrating 
information from different management protocols 
(302), comprising the steps of: 

receiving event data elements (424c) corre- 
sponding with different management protocols 
(302) from said network (118); 
translating said event data elements (424c) into 
respective canonical data structures (424), 
each of said canonical data structures (424) 
including at least one attribute field (427) gen- 
erated by examining a protocol data unit (424c) 
associated with each of said event data ele- 
ments (424c); 

passing said canonical data structures (424) to 
a framework (254) for possible distribution to 
consumer components (534) that are con- 
nected to said framework (254); 
communicating a particular attribute field (427) 
from a consumer component (534) to said 
framework (254) to indicate that said consumer 
component (534) wishes to receive any of said 
canonical data structures (424) with said par- 
ticular attribute field (427); and 
forwarding a canonical data structure with said 
particular attribute field (427) from said frame- 
work (254) to said consumer component (534). 

10. A method for enhancing operation of a manage- 
ment station (1 00) on a network (1 1 8) by correlating 
and integrating information from different protocols 
(302), comprising the steps of: 

receiving event data elements (424c) from said 
network (118); 
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translating each of said event data elements 
(424c) into a canonical data structure, said 
canonical data structure capable of being cor- 
related with other canonical data structures 
(424) corresponding to other event data ele- 5 
ments (424c) regardless of protocols (302) 
associated with said event data elements 
(424c); and 

correlating said canonical data structures (424) 
to derive an intelligent event 10 
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(57) A generic notifications framework (GNF) sys- 
tem (1 03) integrates information from different protocols 
(302) in a management station (100) interfaced with a 
network (118) and permits correlation of the information 
to make more sophisticated management decisions. 
The generic notifications framework system (103) has 
one or more protocol-specific translators (252) in com- 
munication with the network (118), a generic notifica- 
tions framework (254) in communication with the 
translators (252), and one or more consumer compo- 
nents (534) in communication with the framework (254). 
The translators (252) receive event data elements 
(424c) corresponding with different management proto- 
cols (302) from the network (118) and translate the 
event data elements (424c) into respective canonical 
data structures (424). Each of the canonical data struc- 
tures (424) includes (a) a generic field (424a) that is 
common to generally all of the canonical data structures 
(424), (b) one or more attribute fields (427) generated 
by the translator (252) based upon an examination of a 
protocol data unit (PDU) (424c) associated with each of 
the event data elements (424c), and (c) a protocol data 
unit (PDU) (424c) that is generally identical to the native 
PDU that arrived with the event data element. Con- 
sumer components (534) register with the framework 
(254) to receive any canonical data structures (424) 
having particular attribute fields (427). The generic noti- 
fications framework (254) forwards the appropriate 
canonical data structures (424) to appropriate con- 



sumer components (534) based upon the attribute field 
(427) values. A correlator (1406) may be associated 
with the framework (254) to correlate the canonical data 
structures (424) to derive an intelligent event data ele- 
ment, which is essentially the result of an assimilation 
and logical evaluation of various event data elements 
(424c). 
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